This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.
Current networks are comprised of diverse network functions (NFs). These NFs are connected, or chained, in a certain way in order to achieve the desired overall functionality or service that the network is designed to provide. Generally, these NFs communicate with surrounding peers to process and transport control signaling and/or user plane data through standardized communication/network protocols. Most current network services are defined by statically combining network functions in a way that can be expressed using an NF Forwarding Graph or NF Set construct. A major change brought by network functions virtualization (NFV) is that virtualization enables additional dynamic methods rather than just static ones to construct and manage the network function graphs or sets combining these network functions.
In order to fulfil different business needs and capacity requirements, the scalability of a NF/Virtualized Network Function (VNF) becomes an important and key feature for service providers. In Cloud and NFV, scaling in/out is considered as a basic feature and is seen as an enabler for quickly modifying the capacity of products/services on demand so as to meet increasingly business needs, wherein the term “scaling out” refers to adding resources and the term “scaling in” refers to removing resources, e.g. Virtual Machines (VMs) or instances of a VNF.
At scaling of a VFN, ideally, its peer VNF should not be impacted by or aware of the VNF being scaled out or scaled in. For example, IP connections or application level connections use Virtual Internet Protocol (VIP) per VNF to keep service interfaces unchanged. All running/sealing instances of the VNF behind a VIP address share the load of all services to be provided.
However, during today's transition era, especially in telecom domains with lots of traditional equipment being deployed onsite, technology like VIP may not be applicable for scaling of a VNF in a virtualized network, since an instance or instances inside the VNF still have its or their own service interfaces for service connections. When instances are added/removed in a VNF, the service interfaces associated with these instances are also added/removed, and then manual configurations on the peer VNF are needed for adapting the connections via these service interfaces. For example, when a VNF is scaled out, e.g. a new instance is added into the VNF, a connection to the added instance may be initiated manually by configuring an IP connection address the peer VNF shall use. This may involve massive manual operations when a large number of instances will be added or removed, resulting in a high operational and executive cost.
Therefore, there is a need for a more efficient solution applicable for scaling of a VNF in virtualized networks.